Scheint gut Bruder.
I like that you have separated the config object out

My most important question before I proceed:
If I don't cache the config object where/how am I supposed to set/add defaults like for jshintrc above?

ping @stefanpenner

@dschmidt thanks for the reminder I have been traveling. Will review this evening.

@dschmidt this looks fantastic, only tiny feedbacks^

I think for the first pass we can ignore the caching stuff, subsequent work and introduce this.

Looks good. Happy to defer the caching issue for now.

can I provide any help/feedback here (sorry I have been out of town with little time to provide feedback here)

Yup, you can. I am pretty clueless about what's up with tests ... they are hanging for me and having odd issues that I really don't know how to debug.

So if you could walk me through debugging it, that would be rad. Currently I am still at the ownCloud sprint, but could work on it early next week.

I'm still aware of this PR, just been travelling a lot last month and haven't got around to it. Will get back to it soon hopefully, sorry.

No worries im in the same boat

cc @lukemelia

Submitted #2164 to make adding additional environments (as either production or development styles) really simple.

I will attempt some time this Saturday to help get this to completion.

Thanks a lot @stefanpenner. While I know there's probably not much I can do, let me know if I can do anything to help.

And thanks for attempt at temporary fix @rwjblue.

@joshsmith if u can get that PR over the finish line that would be handy.

What still needs to be done? I was able to make the tests pass with a fairly trivial change from config/environment -> config/development in project-test, but it's a little hard for me to follow what might still need attention.

I'm a bit late chiming in here but it's better late than never.

First, since we're in ember-land I think we should make this very ember like and pretty much clone Ember.get, Ember.set, Ember.setProperties API.

This also means config.get,config.set and config.isEnabled should use the . syntax to get/set properties. This allows for arbitrary nesting or properties which currently isn't allowed. It's fixed 2 levels deep right now. A real example of this that wouldn't work: config.isEnabled('ENV.EmberENV.FEATURES.query-params)`

My idea is the API look like:

config.set(keyPath, value);
config.get(keyPath);
config.isEnabled(keyPath);
config.setProperties(keyPath, hash);

Thoughts?

we still intend to solve this, but master has diverged pretty far. I am going to close this, but we will sort this out.

What's the status of this?

Status?

@stefanpenner is there any update on this feature? We are trying to put our app up but we need staging environment support

Please use the existing 3 env. And configure those further with environment variables

Ah, thats pretty obvious in retrospect. For others that come across this i found a decent SO post here to help: http://stackoverflow.com/questions/26403334/how-to-pass-api-keys-in-environment-variables-to-ember-cli-using-process-env @stefanpenner thank you!

Two years later - is support for staging never going to be done? Documentation implies otherwise.

Honestly I just encountered this issue today and can't understand why isn't it added? Am I really supposed to pass variables from bash if I need them for staging, like the @trcarden post above suggests? I'm really lost. There was an issue opened to document it (#5400) but documentation was never done.

@zackthehuman can you paste in the snippet that you wrote?

@nathanhammond I think this is what you're referring to.

I sometimes build my addon's dummy app in order to use it like a demo/api documentation. For certain reasons I am unable to use the production build, so I want to use the development build, but I need to override some settings when I'm building the "apidoc" mode.

// environment.js

if(process.argv.indexOf('--apidoc') !== -1) {
    console.log('This is an apidoc build so the environment settings will be adjusted.');
    ENV.locationType = 'hash';

    // We want to force the country code to be "us".
    ENV.i18n.requestIpCountryCode = 'us';
}

Is there a better way how to add staging environment like production and development? I need to set API_HOST for each environment in my app, but I can't wait another 2 year for support this feature.

@meliborn See the comment above yours. That represents a semi-official recommendation for how to toggle different information on a per-build basis. You'd use that code and something like:

ember build -prod --api-host=asdfasdfasdf

@nathanhammond wrong link?

@wayne-o could you throw me an example please? Can't imagine how to use it without if-env block

@meliborn Corrected link. Literally the comment above yours provides a workaround you can use, and my comment demonstrates how you could use it.

Also, @meliborn

but I can't wait another 2 year for support this feature

This type of communication is not constructive in an open source community. This implies a demand. Our work on Ember is a labor of love. Very few of us are paid to work directly on Ember projects, and if we are those efforts are strongly directed by those who are paying. We're real human beings with hobbies and pastimes and friends and things we do other than this. We strive to be friendly and helpful in spite of this, but I wanted to provide a bit of feedback so you understand that it's frustrating and hurtful to read comments like that. We'd love infinite time to address all things. I assure you. But we must prioritize.